This governance action proposes a measured increase to Plutus memory limits at both the transaction and block level. It represents Part 1 of a staged two-step update.
RCADA voted YES because the proposal is guardrail-compliant, benchmark-supported, and improves developer flexibility without altering monetary policy, treasury funds, or cost model parameters.
This vote applies strictly to Part 1. Any subsequent increase must be independently assessed based on post-enactment mainnet data.
The proposal increases:
maxTxExecutionUnits[memory] from 14,000,000 → 16,500,000maxBlockExecutionUnits[memory] from 62,000,000 → 72,000,000No other protocol parameters are changed.
No Plutus cost model values are modified.
No treasury funds are involved.
The coordinated adjustment preserves the structural ratio between per-transaction and per-block limits, maintaining the current block capacity shape (e.g., four maximum-sized transactions per block).
The stated objective is to reduce friction for Plutus developers and enable more work to be executed within a single transaction or block.
Assessment: Pass
No bundling issues. No treasury implications. No administrative ambiguity.
Assessment: Strong
Ecosystem Benefit:
Improves DApp ergonomics, reduces artificial execution ceilings, and supports scalable application design.
Execution Risk:
Benchmarking indicates sufficient propagation headroom. However, parameter increases create path dependency if widely adopted.
Governance Risk:
Low for Part 1. Future increases must be evaluated cumulatively to avoid incremental drift beyond safe diffusion budgets.
Assessment: Low–Medium (manageable and bounded)
| Dimension | Score (1–5) |
|---|---|
| Constitutional clarity | 5 |
| Governance quality | 4 |
| Execution credibility | 4 |
| Ecosystem value | 4 |
| Risk balance | 4 |
RCADA votes YES on Part 1 of this protocol parameter update.
This proposal reflects disciplined governance design: it is incremental, benchmark-supported, testnet-validated, and compliant with the Cardano Blockchain Ecosystem Constitution v2.4 and its Guardrails.
The increase to Plutus memory limits improves developer flexibility without modifying cost model parameters, monetary policy, or treasury funds. It remains within defined per-epoch adjustment bounds and preserves structural block composition.
I support measured scaling where evidence demonstrates sufficient performance headroom. At the same time, I recognize that parameter increases create forward path dependency once developers build against higher ceilings.
For that reason, this vote applies strictly to Part 1. It does not constitute pre-approval of Part 2. Any subsequent increase must be evaluated independently following observable mainnet performance data, including propagation metrics and real-world usage patterns.
Incremental scaling must remain evidence-driven and constitutionally grounded.
RCADA’s full vote assessment can be found here:
“https://brolloks.github.io/rcada-drep-votes/”